Hash collision avoidance in network routing

ABSTRACT

Network device and method for routing a packet and setting up a new flow. The device includes a packet classifier, a field-selection table, a hash module, and a routing table. A packet is routed by finding an entry in the field-selection table using the packet classifier, selecting bits from the packet based on the entry in the field-selection table, and hashing the selected bits along with an identifier from the packet classifier or the field-selection table, using the hash module. The hash result is used to locate instructions in the routing table. When setting up a new flow, the hash module result may point to an existing entry in the routing table. In such instances, a new entry is added to the packet classifier, such that the hash module will produce a different result that points to an available entry in the routing table.

BACKGROUND

Network devices, e.g., switches, routers, and filters, play an importantrole in data communications. Countless amounts of data are transferredas data packets transmitted over different networks across the world.Each data packet must be channeled from its source to its destination,and network devices play an important role in directing the traffic. Inorder to limit latency, it is important that network device can routetraffic efficiently and accurately.

There are many different components within network devices. Onecomponent found in some network routers is a routing table. A routingtable stores handling instructions, e.g., a next-hop destination or anegress port identifier, for data packets that are to be routed throughthe device. Each entry in the table corresponds to a route. Theserouting tables are sometimes stored using volatile integrated circuitmemory, e.g., SRAMs. Generally, routing tables have limited capacities.In order to stay within the limited capacity, it is important thatnetwork devices store a minimal amount of data for each route in therouting table.

SUMMARY

In one aspect, the disclosure relates to a network device. The networkdevice includes a packet classifier, a field-selection table, a hashmodule, a routing table, and a routing module configured to route apacket. The routing module is configured to determine an entry in thepacket classifier using a received packet, retrieve an identifierassociated with the determined packet classifier entry, choose afield-selection table entry using the retrieved identifier, generate ahash module input by identifying a set of bits of the packet based onthe chosen field-selection table entry, cause the hash module to computea hash result based on the generated hash module input and based on theretrieved identifier, match the hash result to an entry in the routingtable, and obtain processing data for the data packet from the matchingrouting table entry.

In another aspect, the disclosure relates to a method. The methodincludes receiving a packet from a source, determining an entry in apacket classifier using the received packet, retrieving an identifierassociated with the determined packet classifier entry, and choosing afield-selection table entry using the retrieved identifier. The methodfurther includes generating a hash module input by identifying a set ofbits of the packet based on the chosen field-selection table entry,causing a hash module to compute a hash result based on the generatedhash module input and the retrieved identifier, and matching the hashresult to an entry in a routing table. The method includes obtainingprocessing data for the packet from the matching routing table entry.

In another aspect, the disclosure relates to a non-transitorycomputer-readable medium storing computer-readable instructions that,when executed by one or more computing devices, cause at least one ofthe one or more computing devices to perform operations that includereceiving a packet from a source, determining an entry in a packetclassifier using the received packet, retrieving an identifierassociated with the determined packet classifier entry, and choosing afield-selection table entry using the retrieved identifier. Theoperations further include generating a hash module input by identifyinga set of bits of the packet based on the chosen field-selection tableentry, causing a hash module to compute a hash result based on thegenerated hash module input and the retrieved identifier, and matchingthe hash result to an entry in a routing table. The operations furtherinclude obtaining processing data for the packet from the matchingrouting table entry.

BRIEF DESCRIPTION OF THE DRAWINGS

These diagrams and flowcharts are not intended to limit the scope of thepresent teachings in any way. The devices and methods may be betterunderstood from the following illustrative description with reference tothe following figures in which:

FIG. 1 is a diagram of an example network device;

FIG. 2 is a flowchart of an example method for routing a packet usingthe network device shown in FIG. 1;

FIG. 3A is the layout for a typical TCP/IPv4 packet header, includingthe Ethernet frame;

FIG. 3B is the layout for a typical TCP/IPv6 packet header, includingthe Ethernet frame;

FIG. 4 shows an example packet classifier and an example field-selectiontable, as used by the network device shown in FIG. 1;

FIG. 5 shows an example of the hash module used in the network deviceshown in FIG. 1;

FIG. 6 shows an example routing table; and

FIG. 7 is a flowchart of a method for initiating a new flow using thenetwork device shown in FIG. 1.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The various concepts introduced above and discussed in greater detailbelow may be implemented in any of numerous ways, as the describedconcepts are not limited to any particular manner of implementation.Examples of specific implementations and applications are providedprimarily for illustrative purposes.

FIG. 1 shows a diagram of an example network device 100. The illustratednetwork device 100 includes a routing module 101, a maintenance module102, a packet classifier 120, a field-selection table 130, a hash module140, and a routing table 150. The network device 100 includes networkinterfaces 115, through which the network device 100 can receive datapackets from one or more of sources 110 _(a)-110 _(n) (generally “source110”) and can forward the data packets to any number of destinations 190_(a)-190 _(m) (generally “destination 190”). The sources 110 anddestinations 190 can each be a server, a computer, a processor, a mobiledevice such as a smart phone or tablet, a set-top device, or any othersuitable network device. In general, a set of data packets forming acommunication between a source 110 and a destination 190 constitutes aflow. In a two-way exchange between two end points, the end points actas both sources and destinations. Thus, a source 110 in one flow may bea destination 190 for another flow. In some implementations, the networkdevice 100 is an end-host device. For example, the network device 100can be a server that receives requests from one or more of sources 110_(a)-110 _(n), and responds to each request, e.g., by originating datapackets to transmit, or causing another server to transmit, data packetsto the requesting source 110. In some implementations, the networkdevice 100 uses the routing module 101 to direct packets to anothernetwork device, to one of multiple computing processors or modules inthe network device 100, to a particular core of a multi-core processor,to a particular hypervisor, virtual computer, or operating system, or toa specific application or service instance executing on an end-hostserver.

In some implementations, one or more of the various components of thenetwork device 100 are implemented as hardware in an integrated circuit,such as an application specific integrated circuit (ASIC) or fieldprogrammable gate array (FPGA). In some implementations, one or more ofthe various components of the network device 100 are implemented ascomputer executable instructions that are executed by one or morespecial purpose or general purpose processors. In some implementations,one or more of the various components of the network device 100 areimplemented as a mix of special purpose circuits and computer executableinstructions that are executed by a processor. For example, in someimplementations, the packet classifier 120 is implemented as a ternarycontent-addressable memory (TCAM) circuit, the hash module 140 isimplemented as a special purpose hashing circuit, the field-selectiontable 130 and the routing table 150 are implemented using random accessmemory (RAM), and the routing module 101 and the maintenance module 102are implemented as computer executable instructions that are executed bya general purpose computing processor. In some implementations, one ormore of the components or modules are remote from the network device100. For example, in some implementations, the maintenance module 102 isimplemented in a separate controller, e.g., in a controller for asoftware-defined network (SDN). In some implementations, thefield-selection table 130 and/or the routing table 150 are implementedusing volatile memory, such as DRAM, SRAM, FLASH, or other integratedcircuit memory. In some implementations, a computing processor ismulti-core. In some implementations, the network device 100 isimplemented with multiple computing processors.

In operation, the network device 100 receives a packet and determineshow to handle the received packet, e.g., by identifying and forwardingthe packet to a next-hop network device. The process is generallygoverned by the routing module 101. Each packet begins with a sequenceof header bits that identify a communication protocol for the packet andany additional packet information in accordance with the communicationprotocol, e.g., addressing information for the packet. Two exampleformats are illustrated in FIGS. 3A and 3B, described below. The routingmodule 101 processes the initial bits of the packet to identify an entryin the routing table 150 with handling instructions for the packet. Forexample, the handling instruction may specify a network interface 115 touse for forwarding the packet. In some implementations, the networkdevice 100 includes multiple computing processors and the handlinginstructions specify which processor to use for processing the packet.In some implementations, the network device 100 includes multipleservice instances for handling network traffic, and the handlinginstruction may identify a particular service instance to handle thereceived packet.

The routing module 101 identifies the entry in the routing table 150 byprocessing information in the header of the packet. In general, eachcommunication protocol defines an assignment of the header bits intomeaningful fields, where each field has a number of bits and the valuesof those bits is the value of the respective header field. The meaningof a header field value is understood within the context of thecommunication protocol used. The number of bits in a field is typicallyspecified by either the protocol or by the contents of another field inthe header. For example, an address in IPv4 is represented by thirty-twobits, starting at the ninety seventh bit of the IPv4 header (as shown,for example, in the IPv4 header 340 in FIG. 3A), whereas an address inIPv6 is represented by one hundred twenty eight bits, starting at thesixty fifth bit of the IPv6 header (as shown, for example, in the IPv6header 350 in FIG. 3B). Furthermore, a typical data packet uses multipleprotocols in a layered manner. For example, the transmission controlprotocol (TCP) defines a communication verification protocol that relieson a separate addressing protocol such as the Internet Protocol (IP),which, in turn, relies on a framing protocol such as Ethernet. Thus, asingle TCP/IP packet has at least three layers of header information.For example, as shown in FIG. 3A, a typical TCP/IPv4 packet, after aframe delimiter, begins with a fourteen-byte Ethernet frame header 320,followed by a twenty-byte IPv4 header 340, followed by a TCP header 360,which is also typically twenty bytes. Each protocol header contributesinformation used by the routing module 101. For example, the IPv4 headerincludes address information and the TCP header includes portinformation. Therefore, the routing module may be configured todistinguish between protocols and extract information from the differentprotocol headers of a packet using the correct bits, or fields of bits,of the packet.

Accordingly, still referring to FIG. 1, the routing module 101 uses apacket classifier 120 to classify the packet. In some implementations,the packet classifier 120 determines which communication protocols areused by the packet. In some implementations, the packet classifier 120compares the initial bits of a packet to one or more patterns, eachassociated with an entry in the field selection table 130. If a patternmatches to the initial bits of a packet, then the associated entry inthe field selection table 130 indicates which fields (sets of bits) inthe packet to use. In some implementations, the pattern matching isperformed using ternary-logic content-addressable memory (TCAM). In aTCAM, the pattern for each bit can match to a 1, to a 0, or to either.That is, the pattern can designate some of the bits as “don't care” bitsthat will satisfy a comparison with the pattern regardless of the valueof those particular bits. The “don't care” bits are typically indicatedby an “x”. In some implementations, the patterns are ordered in suchthat if multiple patterns can may match to the same packet, the firstpattern in the ordering is used. The last pattern can then be a genericpattern that will match all packet headers and is associated with adefault rule. In some implementations, the packet classifier 120 returnsan identifier for an entry in the field selection table 130. In someimplementations, the packet classifier 120 returns two values: aclassification result and an identifier for an entry in the fieldselection table 130. In some implementations, the classification resultis unique to the pattern matched.

The field selection table 130 is used to identify which data fields inthe header of a packet to process based on the determinedclassification. In some implementations, the field selection table 130specifies, for each communication protocol or combination ofcommunication protocols, which bits of the header(s) to use. Theselected bits are used as part of an input to the hash module 140. Forexample, an entry in the field selection table 130 may be a bit maskthat, when applied to the packet header with a logical AND operation,zeros-out or clears the header bits that are not selected (effectivelyleaving only the selected field values). In some implementations, therouting module 101 extracts the results into a data structure, ann-tuple, holding the selected field data. In such implementations, then-tuple is passed to the hash module 140. In some implementations, thebit mask identified by an entry in the field selection table 130 isapplied to the header, or to a single contiguous block of bits from theheader, and the result is passed to the hash module 140. That is, theentire packet prefix, or a single contiguous block of bits from thepacket, is used with bits for non-selected fields simply set to aconstant, e.g., zero. In some implementations, the bit mask is stored ina compressed manner, where each bit of the mask represents multiplebits, e.g., one bit in a byte-mask represents eight bits of a bit-mask.In some implementations, an entry in the field selection table 130identifies specific bits, or sets of bits, to use from the header. Insome implementations, an entry in the field selection table 130identifies specific sets of bits using a compressed encoding whereineach bit of the encoding corresponds to a range of bits in the header.For example, if a bit is “on” (i.e., set to 1), then the correspondingrange (e.g., the n^(th) octet or byte, or the bits from bit x to bit yof the header) is extracted. In some implementations, the resultingvalue(s) is copied into a memory register.

The network device 100 includes a hash module 140, used to hash an inputvalue (or values). For example, the hash module 140 may be used to hashbit values selected from a packet's header data, as indicated by theentry in the field selection table 130. In some implementations, valuesin addition to the bits selected from a packet header are included inthe input values to the hash module 140. The hash module 140 processesthe input values and produces a hash value. In some implementations, thehash value is of a fixed bit-length. In some implementations, anidentifier associated with a result from the packet classifier 120 isincluded in the input values. For example, in some implementations, theclassification result is included with the bit values from the packet'sheader data. In some implementations, the hash module 140 produces ahash result value from a sequential stream of input values. For example,the hash module may accept any number of input values. In some suchimplementations, each input value is limited to a predetermined numberof bits (e.g., 32 or 64). In some such implementations, the hash moduleresult is updated as each input value is received, such that the resultis impacted by every bit received as input. In some implementations, thehash module is placed in an initial state prior to generating a result.In some implementations, the first input to the hash module is a seedvalue. In some implementations, the hash module implements a hashalgorithm in special hardware, e.g., in an ASIC or FPGA.

The routing module 101 uses the resulting hash value, or a portion ofthe resulting hash value, to select an appropriate entry in the routingtable 150. In some implementations, the hash module 140 produces a2N-bit (e.g., 32 bit) hash value and the routing module 101 only usesthe lower order (or, alternatively, the higher order) N bits (e.g., 16bits) of the hash value. In some implementations, the routing table 150is stored in a manner facilitating fast look-ups using the hash value.For example, in some implementations, the routing table 150 may be keyedto, or indexed by, the hash module 140 output values. In someimplementations, the routing table 150 may be implemented as an array,two-way associative array, four-way associative array, n-way associativearray, or successive-row-lookup table.

The maintenance module 102 maintains, and modifies as necessary, thecontents of the packet classifier 120, field selection table 130, androuting table 150. In some implementations, the maintenance module isimplemented as hardware in an integrated circuit, such as an ASIC orFPGA. In some implementations, the maintenance module 102 is implementedas computer executable instructions that are executed by a specialpurpose or general purpose processor. In some implementations, themaintenance module 102 is on a separate network controller, such as anSDN controller, remotely maintaining the components of the networkdevice 100. In some implementations, the maintenance module 102 updatesthe routing table 150 for each new packet flow. In some implementations,the maintenance module 102 updates the routing table 150 for a newpacket flow if the new flow meets certain requirements. For example, insome implementations, the maintenance module 102 updates the routingtable 150 to ensure a consistent route when a flow indicates a need fora certain quality of service (QoS) or in-order delivery. In someimplementations, the maintenance module 102 updates the packetclassifier 120. For example, in some implementations, the maintenancemodule 102 updates the packet classifier 120 with an additionalclassifier pattern used to differentiate between two distinct packetflows that result in the same hash result value from the hash module140. The new pattern will have a new, internally unique, classificationresult, and may be associated with an existing entry in the fieldselection table 130 or may be associated with a new entry in the fieldselection table 130.

FIG. 2 is a flowchart of an example method 200 for routing a packetusing the network device shown in FIG. 1. In brief overview, the method200 includes receiving a packet (step 210), retrieving an identifierassociated with a packet classifier entry (step 220), and choosing afield selection table entry (step 230). The method further includesgenerating a first hash module input by identifying a set of bits of thereceived packet (step 240), hashing the first hash module input togetherwith the identifier (step 250), matching the hash result to an entry inthe routing table (step 260), and obtaining a routing instruction fromthe routing table entry (step 270). The network device then processesthe packet according to the obtained instruction.

As indicated above, the method 200 begins with receiving a packet (step210). The packet can be received from any of the sources 110 connectedto the network device 100. The packet can be received via a wirednetwork connection or wirelessly. In general, each packet begins with asequence of header bits that identify a communication protocol for thepacket and any additional packet information in accordance with thecommunication protocol, e.g., addressing information for the packet. Adata packet includes, after the header bits, additional data bitsreferred to as the payload. The payload may encapsulate another packet,e.g., a packet in a format of another protocol. The payload for anencapsulated packet begins with another header. Thus, as shown in FIGS.3A and 3B, an Ethernet packet may encapsulate an IP (IPv4 or IPv6)packet, which may encapsulate a TCP packet (or a UDP packet, or an ICMPpacket, or any other protocol packet). Each encapsulation is a layer,and the header for each layer specifies information that may be usefulin determining how to handle the packet. For example, the IP layerincludes a source address, a destination address, and a protocolindicator for the next-layer protocol of an encapsulated packet (e.g., 1for ICMP, 6 for TCP, 17 for UDP, etc.). Similarly, the TCP layerincludes identifiers for a source port and a destination port, and alsoincludes control flags indicating a flow state, e.g., a synchronization(SYN) flag used to initiate a flow and a final packet (FIN) flag used toterminate an existing flow.

Continuing with FIG. 2, after receiving a packet (step 210), the routingmodule 101 retrieves an identifier for the packet using the packetclassifier 120 (step 220). A packet classifier 120 matches a receivedpacket with a packet classifier entry. In some implementations, thepacket classifier 120 will parse the packet header to determine specificinformation associated with the packet, such as protocol, source IPaddress and destination IP address. In some implementations, the packetclassifier 120 will compare the packet header to one or moreclassification patterns. For example, in some implementations, thepacket classifier 120 is a TCAM. In general, a packet may satisfyconditions for multiple possible classifications. In someimplementations, the packet classifier 120 prioritizes or orders theclassification patterns such that the packet is classified according tothe highest priority (highest order or “first”) pattern it satisfies.For example, the packet classifier 120 may have a low order genericpattern for all IPv4 packets, a higher order pattern for all TCP/IPv4packets, and a higher order pattern for TCP/IPv4 packets addressed to aparticular address or range of addresses (e.g., a sub-net). If aTCP/IPv4 packet arrives addressed to an address in that range, it wouldsatisfy all three patterns, but the prioritization determines that itshould be classified using the highest order pattern. In someimplementations, the packet classifier 120 has a maximum number ofentries. In some implementations, a smaller number of entries may resultin a reduced level of electrical power consumption. For example, wherethe packet classifier 120 is implemented as a TCAM, a TCAM with at most128 or 256 entries will use significantly less power than a TCAM withthousands of entries.

The routing module 101 uses the retrieved identifier to identify anentry in the field-selection table (step 230). Each entry in thefield-selection table 130 indicates how to parse or process the headerinformation for a packet. In some implementations, an entry indicateswhich bits (or sets of bits) of the packet are to be used as inputvalues to a hash module 140. In some implementations, multiple packetclassifier entries may correspond to a same field-selection table entry.In some implementations, the packet classifier 120 is implemented as aTCAM and each entry in the TCAM corresponds to (or indexes) an entry inthe field-selection table 130. In some such implementations, the entriesin the field-selection table 130 are data structures including anidentifier (e.g., an identifier for an entry in the packet classifier120) and a field selection indicator (e.g., a bit selection pattern, asdescribed above). In some implementations, the identifier is anarbitrary number selected as a “Seed” value that, when passed to thehash module 140 as an input value, causes the hash module 140 togenerate a particular hash result value (or causes the hash module 140to generate a hash result value other than a particular hash resultvalue). In brief, as discussed in more detail below, in someimplementations, the hash result value corresponds to an entry in therouting table 150 and the Seed value may be selected so that hash resultvalue corresponds to a particular entry in the routing table 150. Thus,in some implementations, at steps 220 and 230, the routing module 101uses the packet classifier 120 to identify an entry in thefield-selection table that specifies an identifier or Seed value and abit-selection instruction.

The routing module 101 then selects bits from the header(s) of thereceived packet (step 240) based on the bit-selection instruction fromthe entry in the field selection table. One or more of the fields of thepacket header may be selected. For example, the entry may indicateselection of bits representing the packet's source IP address,destination IP address, next level protocol, destination port, andsource port. As another example, the entry may indicate selection ofbits representing the packet's destination IP address sub-net (e.g., thefirst 24 bits of an IPv4 address), next level protocol, destinationport, and the TCP synchronization control flag (SYN). In someimplementations, the routing module 101 extracts the designated bitsfrom the packet header and passes the designated bits to a hash module140 as input. In some implementations, the routing module 101 identifiesa single contiguous block of bits from the packet, applies a bit mask tothe block, the bit mask identified in the entry in the field selectiontable, and passes the result to a hash module 140 as input. For example,the single contiguous block of bits may be the first forty-four bytes(three hundred fifty two bits) after the Ethernet header, which issufficient to include the twenty bytes of an IPv4 header or the fortybytes of an IPv6 header, and the first few bytes of an encapsulatedheader. In some implementations, the routing module 101 also passes theidentifier (from step 220) or Seed value (from step 230) to the hashmodule 140 as input.

The routing module 101 uses the hash module 140 to determine a hashvalue for the input values (step 250). In general, the hash module 140accepts the bits selected from the packet header, and any additionalinput bits (e.g., an identifier or Seed value), as input. The hashmodule 140 implements a hash function which generates a hash value basedon the input values. In some implementations, the hash module 140calculates the hash result using a hash function such as MD5, Jenkins,or MurMur. In some implementations, the hash module 140 uses a table ofrandom numbers for generating hash values. In some implementations, thehash module 140 uses a linear-feedback shift register (LFSR). Typically,a hash function uses every input value such that a change in any oneinput bit will result in a different output value. The output value fora hash function is typically represented with fewer bits than the inputvalue. For example, the input values may be 128 bits that include two32-bit IPv4 addresses, port information, protocol information, and aseed value, and the input values may be reduced to, for example, a32-bit hash result value. This is a form of lossy compression, whichmeans that, for such functions, there must be at least one output valuethat can be reached from at least two different input values. When thishappens, there is a collision between the different input values thatresulted in the same output hash value. As introduced above, in someimplementations, the Seed value may be adjusted to avoid collisionevents. Further discussion of collisions, and methods of addressingcollision events, is presented below.

Continuing to refer to FIG. 2, in the method 200, the routing module 101takes the output of the hash module 140 and matches it to an entry inthe routing table (step 260). In some implementations, the routing table150 is a hash table keyed to the results of the hash module 140. In someimplementations, the hash result value is an index into the routingtable 150. In some implementations, the routing module 101 uses the hashresult, or a portion of the hash result, to calculate an index into therouting table 150. In some implementations, an index into the routingtable 150 is a memory address allowing for direct access to memorystoring an entry in the routing table 150. In some implementations, therouting table 150 has a fixed number of entries such that each possiblehash result value can be translated to a specific entry in the routingtable 150. For example, there could by 2¹⁶ entries and the lower-order16 bits of the hash result value identifies a respective entry. Eachentry is either empty or is populated with routing instructions thatcorresponds to a packet with header information that results in acorresponding hash value. In some implementations, the entry identifiedis a generic entry for packets flowing to a subnet.

In some implementations, matching the hash result to an entry in therouting table includes verifying the match. For example, each routingtable entry may include match data that can be used to confirm the entryis correct for a particular packet. Match data is described in moredetail below. In some implementations, matching the hash result to anentry in a the routing table includes deriving a routing table indexfrom a first subset of a set of hash result bits (the binaryrepresentation of the hash result), locating an entry in the routingtable from the routing table index, identifying a match data item storedin the entry, and verifying that the match data item is equal to asecond subset of the set of hash result bits. In some implementations,the second subset of bits includes at least one bit not in the firstsubset of bits. In some implementations, the first subset of bits doesnot intersect with the second subset of bits. In some implementations,the first subset of bits is the x lower order bits of an n-bit hashresult, and the second subset of bits is the upper n−x bits of the n-bithash result. In some implementations, another characteristic of thepacket is used to verify the match.

In some implementations, the entry identified is a specific entrycreated for a particular flow of data packets. For example, in someimplementations, a new entry is added to the routing table 150 when anew flow is detected, and the new entry indicates specific instructionsfor the new flow. A new flow may be detected, for example, when a TCP/IPpacket arrives with the SYN flag set, indicating the beginning of a TCPhandshake. In some implementations, if a new flow is detected and theresulting hash value points to (or indicates) an entry in the routingtable 150 that is already in use, this indicates a collision. In someimplementations, when a collision is detected, a new entry is added tothe packet classifier 120 such that the identifier for the entry in thepacket classifier 120 is changed, thereby altering the input to the hashmodule 140 and generating a new hash result value. In someimplementations, a collision may be detected in other ways, as describedbelow.

The routing module 101 obtains the routing instruction from the entry inthe routing table (step 270) and processes the packet using the routinginstruction. In some implementations, the routing table entry identifiesa network interface 115 through which the network device 100 forwardsthe packet. In some implementations, the routing table entry identifiesa next-hop address. In some implementations, the routing table entryincludes an instruction to allow or drop the packet. In someimplementations, the routing table entry includes an instruction toprocess the packet before forwarding, e.g., to fragment the packet or toupdate a time-to-live field or a hop limit field. The network deviceprocesses the packet using the routing instructions. Thus, for example,the network device can forward the packet to the proper destination 190.

FIG. 3A shows the format 314 for the headers of a typical TCP/IPv4packet transmitted via Ethernet. In broad overview, the illustratedformat includes an Ethernet frame 320, an Internet Protocol (IP) version4 header 340, a transmission control protocol (TCP) header 360, and thebeginning of the encapsulated data 380, i.e., the payload.

A TCP/IPv4 packet, as shown in FIG. 3A, begins with a new packetpreamble and delimiter, most of which is not shown. After the delimiter,an Ethernet frame header 320 includes a media access control (MAC)address for the packet's immediate destination (i.e., the network devicereceiving the packet) and a MAC address for the packet's immediatesource (i.e., the network device transmitting the packet). A MAC addressis 48 bits, or six 8-bit octets. The Ethernet frame header 320 alsoincludes a 16-bit “Ethertype” indicator, which may indicate the size ofthe frame or the protocol for the Ethernet payload (i.e., the next levelprotocol). The Ethernet frame header 320 is followed by the Ethernetpayload, which begins with a header for the encapsulated packet.

FIG. 3A shows the format 314 for the headers of a typical TCP/IPv4packet, thus the Ethernet frame header 320 is followed by an IPv4 header340. The first four bits indicate the Internet Protocol version (i.e.,4). The next sets of bits indicate the header length (IHL), flags todifferentiate service requirements (DSCP, used, e.g., to express qualityof service (QoS) requirements), explicit congestion notification (ECN),a length for the IP packet, a packet identification shared across packetfragments, IP flags, and a fragment offset. After the packetfragmentation bits, the IPv4 header 340 indicates a time to live (TTL)for the packet, which may be measured in time (e.g., seconds) or hops(number of network devices that can forward the packet). After the TTL,the IPv4 header 340 indicates the protocol for the next levelencapsulated packet. For example, a 1 indicates the Internet controlmessage protocol (ICMP), a 6 indicates TCP, and 17 indicates the userdatagram protocol (UDP). The IPv4 header 340 further includes a headerchecksum, which must be recalculated every time the header changes,e.g., whenever the TTL is updated. The IPv4 header 340 next specifies a32-bit source address and a 32-bit destination address. Additionalheader fields may be used, but may be omitted and are not shown in FIG.3A.

After the IPv4 header 340, FIG. 3A shows a TCP header 360. The typicalTCP header begins with a 16-bit source port identifier and a 16-bitdestination port identifier. A TCP port is a virtual port, typicallyused to indicate the type of data in the payload so that the receivercan pass the packet to the correct application. The TCP header 360 thenspecifies sequencing information including a sequence number for thepacket, an acknowledgement number, and a data offset. The TCP header 360includes control flags, e.g., SYN, FIN, and ACK, and additional controlinformation such as the window size, a checksum, and other options. Thedata encapsulated 380 begins after the TCP header 360.

FIG. 3B shows the format 316 for the headers of a typical TCP/IPv6packet transmitted via Ethernet. In broad overview, the illustratedformat includes an Ethernet frame 320, an Internet Protocol (IP) version6 header 350, a transmission control protocol (TCP) header 370, and thebeginning of the encapsulated data 390, i.e., the payload. The Ethernetframe 320 in the illustrated packet is identical to the Ethernet frame320 in FIG. 3A.

FIG. 3B shows the format 316 for the headers of a typical TCP/IPv6packet, thus the Ethernet frame header 320 is followed by an IPv6 header350. The first four bits indicate the Internet Protocol version (i.e.,6). The next sets of bits indicate a traffic class, a flow label, andthe payload length. After the payload length, the IPv6 header 350indicates a Next Header, which is the same as the protocol identifierused in IPv4. That is, it may be a 1 for ICMP, a 6 for TCP, a 17 forUDP, or any other number indicating an associated protocol for the nextheader in the packet. The IPv6 header 350 then indicates a hop limit forthe packet, equivalent to the TTL of IPv4 when used to specify thenumber of network devices that can forward the packet. After the hoplimit, the IPv6 header 350, specifies a 128-bit source address and a128-bit destination address. Additional header fields may be used, butmay be omitted and are not shown in FIG. 3B. There is no checksum for anIPv6 header, eliminating one of the bottlenecks in IPv4 packetprocessing.

After the IPv6 header 350, FIG. 3B shows a TCP header 370. The TCPheader 370 is identical to the TCP header 360 shown in FIG. 3A, but theoffsets from the Ethernet frame 320 are increased because the size of anIPv6 header 350 is larger than the size of an IPv4 header 340. The dataencapsulated 390 begins after the TCP header 370.

FIG. 4 illustrates an example of a packet classifier 420 and an exampleof a field selection table 430. The illustrated packet classifier 420 isshown with patterns expressed in hexadecimal, such that each four bitsection of the header is represented by a value in the range 0-9, A-F,or by an X for “don't care.” The patterns illustrated begin with the IPheader, although in some implementations the patterns begin with theEthernet frame, e.g., so that the source MAC address can be used in thepatterns. The illustrated packet classifier 420 begins with a lowestpriority filter 421 matching any IPv4 packet with an IP header of twentyoctets and a filter 422 matching any IPv6 packet. The packet classifier420 also includes a filter 423 matching any TCP/IPv4 packet and a filter424 matching any TCP/IPv6 packet. The packet classifier 420 includes ahigher priority filter 425 matching a TCP/IPv4 packet from address1.2.3.4 to address 5.6.7.8, with a destination port of 80 (shown inhexadecimal as 0050). The packet classifier 420 also includes a higherpriority filter 426 matching a TCP/IPv6 packet from address0102:0304:0506:0708:0910:1112:1314:1516 to address1718:1920:2122:2324:2526:2728:2930:3132.

Each row of the example field selection table 430 corresponds to a rowof the example of a packet classifier 420. Thus a packet that satisfiesthe highest priority filter 426 is associated with a corresponding entry436 that indicates where the address bits are in the header. An IPv4packet that does not satisfy any of the higher priority filters willmatch the lowest priority filter 421, which corresponds to an entry 431that indicates where IPv4 address bits are located in the header. Asindicated above, while the example field selection table 430 includesone entry for each entry in the packet classifier 420, in some otherimplementations, more than one entry in the packet classifier 420 maycorrespond to a common entry in the field selection table 430. Forexample, in some implementations, the filters 421, 423, and 425, whicheach match to an IPv4 packet, each correspond to a single entry in thefield selection table 430 that identifies, for example, bits common toany IPv4 header.

FIG. 5 shows an example structure of the inputs and outputs of a hashmodule used in the network device shown in FIG. 1. The example structureof a hash module 140 takes, as input, bits from the packet 520 and aseed value 510, and generates a hash result value 530. In someimplementations, the bits from the packet 520 are the values for variousprotocol fields indicated by an entry in the field selection table 130.In some implementations the bits from the packet 520 are a block of bitsfrom the header with some of the bits therein set to zero. Althoughshown in FIG. 5 as multiple fields 520, the bits from the packet 520 mayonly be one field, may be a single block of data representing multiplefields, may be multiple fields, and/or may include bit values that havebeen set to a constant. In some implementations, the seed value 510 isan identifier specified by the packet classifier 120. In someimplementations, the seed value 510 is an identifier or Seed valuespecified by an entry in the field selection table 130. Because the hashmodule processes all of the input bits, different values for the seedvalue 510 will cause the hash module 140 to produce different values forthe hash result 530, without any change to the input values 520 selectedfrom the packet header. In some implementations, the hash result 530 isa fixed number of bits. In some implementations, the lower order bits ofthe hash result 530 are used to locate an entry in the routing table150. For example, in some implementations, the routing table 150 hasspace for 2¹⁶ entries, and the lower order sixteen bits of the hashresult 530 uniquely identify one of those 2¹⁶ spaces in the routingtable 150. In some implementations, the routing table 150 is dynamicallysized and an intermediary index maps hash result values to indices intothe dynamically sized routing table 150. In some such implementations,the intermediary index has the same number of entries as possible hashresult values 530, e.g., 2¹⁶ entries for a 16 bit result. In some suchimplementations, the intermediary index has a smaller number of entries,e.g., m, and the entry for a hash result values is found at the hashresult value modulo m. These implementations have an increasedlikelihood of hash collisions.

In some implementations, the hash result 530 is an n-bit value (e.g., a64-bit value or a 32-bit value) and the lower order n−x bits (e.g., 16bits) are used to determine an index into the routing table 150. In someimplementations, the routing module 101 confirms that the entry at thedetermined index is the correct entry (and not an entry reached via ahash collision) by matching one or more stored values with confirmationvalues (referred to as “match data”). In some such implementations, thefull n-bit hash result value 530 may be used as match data. For example,in some implementations, the routing table 150 includes, in each entry,a stored copy of the n-bit value that matches to the entry even thoughonly n−x bits are used to locate the entry. In some suchimplementations, only the additional bits of the hash value not includedin the n−x bits used to locate the entry are stored as match data. Therouting module 101 can confirm that the entry is correct by matching thestored n-bit value (or stored portion thereof) to the n-bit hash resultvalue 530. As an example, in some implementations, the hash result 530is 64 bits and only the higher order 48 bits are stored as match data.The lower order 16 bits are used to locate an entry in the routing table150 and the remaining bits are used to confirm a match. In some suchimplementations, no other match data is stored. In some implementations,the match data includes bits from one or more of the input fields 520.For example, in some implementations, the match data includes an addressfield from the packet header. In some implementations, the match data isan input value 520 that is common to all packets for which the entryshould match. In some implementations, the match data is stored in acompressed form. In general, a routing table storing less match datawill use less memory and require less circuitry and electrical power forverifications with match data. In some implementations, no match data isstored and no verification is performed.

FIG. 6 shows an example structure of a routing table 150 with storedmatch data. The example structure shows the routing table 150implemented as an associative array containing two tables, an indextable 651 and a data table 652. The routing table 150 is accessed usingkey data 610, which includes a hash value 614, e.g., bits from a hashresult 530. When a routing module 101 accesses the routing table 150 toidentify routing instructions for a packet, the routing module 101passes in the hash value 614, which is then converted to an index usingthe index table 651. The index is used to locate a corresponding entryin the data table 652. In some implementations, the key data 610 alsoincludes match data 612.

The index table 651 maps hash values to indices. The index table 651 isordered by hash values such that an entry for an input hash value 614can be quickly located in the index table 651. For example, in someimplementations, the index table 651 is structured such that each entryis at a memory location addressed by a start address plus the respectiveinput hash value multiplied by a constant (e.g., the size of an entry inthe index table 651).

The data table 652 is ordered by the indices from the index table 651.As shown in FIG. 6, in some implementations, each populated entry in thedata table 652 includes confirmation match data and routinginstructions. In some implementations, the data table 652 does notinclude the confirmation match data. In some implementations, theconfirmation match data includes multiple values, e.g., a valuerepresentative of a source or destination address, a valuerepresentative of a source or destination sub-net, a hash value, or anyother data that may be used as confirmation match data. In someimplementations, the confirmation match data is the hash result value530 produced by the hash module 140 (see FIG. 5). In some suchimplementations, the hash value 614 used as key data 610 for the routingtable 150 is a portion of the hash result value 530 stored asconfirmation match data. For example, the input hash value 614 may beonly the lower (or higher) order bits of the hash result value 530. Insome implementations, the key data 610 is a subset of the bitsrepresenting the hash result value 530, and the match data is adifferent subset of the bits representing the hash result value 530. Insome implementations, the confirmation match data is the same data thatwas passed into the hash module 140. In some implementations, theconfirmation match data is a subset of the data that was passed into thehash module 140. In some such implementations, the confirmation matchdata may include less information than the data that was passed into thehash module 140. In some implementations, the confirmation match data iscompressed. In some implementations, the index table 651 and the datatable 652 are n-way associative. For example, the index table 651 andthe data table 652 may be two-way associative, such that the data table652 includes, for each entry, the hash value that corresponds to thatentry (from the index table 651).

In some implementations, the match data 612 is also passed in as aninput value 610. In such implementations, if the match data stored inthe entry matches the input match data 612, then the routing instructionstored at the entry is returned 620. If there is no entry, the packetmay belong to a new flow and the maintenance module 102 updates thetables accordingly. If there is an entry, but the match data in the datatable 652 does not match to the input match data 612, then there is acollision. That is, the values selected from the packet hashed into ahash value that is already in use by packets in another flow. Thispacket, too, is for a new flow and the maintenance module 102 updatesthe tables accordingly. In some implementations, the match data 612 isonly passed in as an input value 610 for a new flow. For example, insome implementations, the maintenance module 102 may receive aninstruction to establish a new flow and uses the match data 612 toverify that the newly established flow does not have a collision with anexisting flow.

In some implementations, when there is a new flow with a hash collisionwith an existing entry in the routing table 150, the maintenance module102 updates the packet classifier 120 to add a new entry for the newflow, such that the new flow is associated with a new identifier. Thenew entry in the packet classifier 120 may correspond to an alreadyexisting entry in the field selection table 130, or the new entry in thepacket classifier 120 may correspond to a new entry in the fieldselection table 130. In either case, the updates result in aconfiguration for the new flow such that the data extracted from packetsin the flow, along with the new identifier, cause the hash module 140 togenerate a distinct hash result 530 (as shown in FIG. 5). The new hashresult can be used, e.g., as an input value 610, to identify an entry inthe routing table 150 for the new flow. In some implementations, themaintenance module 102 configures the entry with routing instructionsfor the flow. In some implementations, the maintenance module 102verifies that the entry is not already in use, and, if it is, modifiesthe identifier associated with the flow so that the hash module 140 willgenerate a different result.

FIG. 7 is a flowchart of an example method for initiating a new flowusing the network device shown in FIG. 1. In brief overview, the method700 includes receiving an indication of a new flow (step 701),retrieving an identifier associated with packet classifier entry (step702), and choosing a field selection table entry (step 703). The methodfurther includes generating a hash module input by processing a packetof the new flow (step 704), hashing the generated input along with theidentifier (step 705), and detecting a collision (step 706). If acollision is detected, the method 700 includes adding a new entry to thedata packet classifier (step 707), assigning a new identifier for thenew entry in the data packet classifier (step 708), and hashing thegenerated hash module input and the new identifier to produce a new hashresult (step 709). The method 700 then verifies that the new hash resultdoes not have a collision with an existing routing table entry (step710). If there is a collision at step 710, the method 700 repeats step708, assigning a different new identifier for the new entry. Once thereare no collisions (at step 706 or step 710), the method 700 includesadding an entry to the routing table (step 720).

As indicated above, the method 700 begins with the maintenance module102 receiving an indication to initiate a new data communication flow(step 701). In some implementations, the indication is an instructionreceived by the maintenance module 102. For example, in someimplementations, an application or service instance on an host servermay initiate a flow by sending an instruction to the maintenance module102. In some such implementations, the application or service instancedesignates specific packet handling instructions for the new flow. Forexample, the host server can request that acknowledgment packets for anew data stream be directed to a particular stream management instance.In some implementations, the maintenance module 102 detects a new flowas a previously unseen flow. In some implementations, the packetclassifier 120 classifies a packet as one initiating a new flow. Forexample, the packet classifier 120 may detect the beginning of a TCPhandshake, as indicated by a SYN flag set in the TCP packet header. Insome implementations where the data packet classifier 120 is implementedas a TCAM, there is a TCAM pattern to match one or more flow initiationpackets. For example, in some implementations, the TCAM has a highpriority pattern for identifying a TCP packet with the SYN flag set,which is interpreted by the network device to indicate a new flow. Insome implementations where the data packet classifier 120 is implementedas a TCAM, receiving a packet with a packet header that matches to thedefault row of the TCAM may initiate a new flow. In someimplementations, an indication of a new flow includes an indication of adesired routing instruction for the new flow. In some implementations,the maintenance module 102 determines a desired routing instruction fora new flow. For example, the maintenance module 102 may accessadditional network topology information to identify a next-hop devicefor packets in the new flow.

The method 700 includes the maintenance module 102 retrieving anidentifier associate with a packet classifier entry (step 702). Thisstep is analogous to step 220 in FIG. 2. The method 700 includes themaintenance module 102 choosing a field-selection table entry (step703), this step is similarly analogous to step 230 in FIG. 2. The method700 includes the maintenance module 102 selecting bits from a packet ofthe flow (step 704). This step is analogous to step 240 in FIG. 2. Themethod 700 also includes hashing the selected bits and the identifier(step 705). This step is analogous to step 250 in FIG. 2. As with step250 in FIG. 2, step 705 in FIG. 7 includes using the identifier as aseed value to a hashing function.

In the method 700, the maintenance module 102 then detects whether ahash collision has occurred (step 706). A collision is detected, forexample, when the routing table 150 does not have an empty location atthe index specified by the hash result 530 for the new flow. In someimplementations, a collision is detected if there exists an entry withdifferent match data as compared to match data for the new flow. In someimplementations, a collision is detected if there exists an entry with adifferent routing instruction as compared to the desired routinginstruction for the new flow, and no collision is detected if therouting instruction in the routing table 150 is the desired routinginstruction for the new flow. That is, if a new flow is established andpackets for that new flow would cause the routing module 101 to accessan entry in the routing table that is populated with handlinginstructions prior to establishing the flow, then there is a collision.However, if those handling instructions are the same as the desiredhandling instructions, in some implementations, the collision is ignoredbecause the new entry would have the same handling instructions as theexisting entry. In some implementations, a collision is detected unlessthe returned location in the routing table 150 is empty, which indicatesthat the routing instruction for the new data communication flow may bestored at the returned location in the routing table 150.

If a collision is detected at step 706, the method 700 includesestablishing a new identifier for the flow, e.g., by adding a new entryto the data packet classifier (step 707), assigning a new identifier forthe new entry in the data packet classifier (step 708), and hashing thegenerated hash module input and the new identifier to produce a new hashresult (step 709). When adding a new entry to the data packet classifier(step 707), the new entry in the data packet classifier 120 is selectedto match packets of the new flow, but not packets of flows already beingprocessed. In some implementations, the next entry is selected to matchpackets only of the new flow. In some implementations, the maintenancemodule 102 identifies the pattern previously used to classify a packetfor the flow and adds additional criteria to the pattern, specific tothe packet classified. For example, if the packet matched aclassification pattern that specified the packet's destination sub-net,but not the full destination address, the maintenance module 102 adds anew classification pattern that specifies the packet's full destinationaddress.

The new classification pattern corresponds to a new identifier assignedfor the new entry in the data packet classifier (step 708). In someimplementations, the new identifier is an output value from the packetclassifier. In some implementations, the new identifier is stored in thefield selection table 130, e.g., as a Seed value. In someimplementations, the new identifier is selected at random. In someimplementations, the new identifier is selected in a deterministicmanner, e.g., by incrementing a counter.

If a collision was detected at step 706, the method 700 includes, afterestablishing a new identifier for the flow in step 708, hashing thegenerated hash input from step 704 and the new identifier (step 709).Because the inputs are now different, the hashing at step 709 results ina new a new hash value. The result of the hashing at step 709 is used toidentify an entry location in the routing table. The new hash value willalmost always correspond to a different entry in the routing table 150.If there is a collision (step 710), the method 700 returns to step 708and assigns a new identifier for the entry in the data packet classifier(added in step 707). In some implementations, steps 708, 709, and 710are repeated until there is no collision. In some implementations, aftera predetermined number of iterations without avoiding a collision, anerror condition is triggered. In some implementations, after apredetermined number of iterations without avoiding a collision,additional steps are taken to modify the hash output, e.g., byassociating the new entry in the packet classifier with a differentfield-selection table entry.

When there are no collisions detected at step 706 and/or step 710, themethod 700 includes adding, by the maintenance module 102, a new entryto the routing table (step 720), the entry containing the desiredrouting instruction and match data for the flow. In someimplementations, the new entry also contains the hash result from step709. In some implementations, the match data is a portion of the hashresult from step 709. For example, in some implementations, the hashresult is a 64-bit value and the match data is the higher order 48 bitsof the hash result. In some such implementations, the lower order 16bits of the hash result are used to locate an entry in the routing tableand the higher order 48 bits are used to verify a match. Packetsreceived after completion of the method 700 are routed using the methodexplained in relation to FIG. 2, which locates and retrieves the routinginstructions and associated data stored in step 720.

In some implementations, the maintenance module 102 removes entries fromthe routing table 150 for flows that have ended, terminated, or becomestale. For example, the packet classifier 120 may detect a TCP teardown,as indicated by a FIN flag set in the TCP packet header. In someimplementations where the data packet classifier 120 is implemented as aTCAM, there is a TCAM pattern to match one or more flow terminationpackets. In some implementations, the maintenance module 102periodically removes entries from the routing table 150 that have notbeen used for a threshold length of time or that were established morethan some predetermined period of time prior.

Implementations of the subject matter and the operations described inthis specification can be implemented in digital electronic circuitry,or in computer software embodied on a tangible medium, firmware, orhardware, including the structures disclosed in this specification andtheir structural equivalents, or in combinations of one or more of them.Implementations of the subject matter described in this specificationcan be implemented as one or more computer programs embodied on atangible medium, i.e., one or more modules of computer programinstructions, encoded on one or more computer storage media forexecution by, or to control the operation of, a data processingapparatus. A computer storage medium can be, or be included in, acomputer-readable storage device, a computer-readable storage substrate,a random or serial access memory array or device, or a combination ofone or more of them. The computer storage medium can also be, or beincluded in, one or more separate components or media (e.g., multipleCDs, disks, or other storage devices). The computer storage medium maybe tangible and non-transitory.

The operations described in this specification can be implemented asoperations performed by a data processing apparatus on data stored onone or more computer-readable storage devices or received from othersources.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, object, orother unit suitable for use in a computing environment. A computerprogram may, but need not, correspond to a file in a file system. Aprogram can be stored in a portion of a file that holds other programsor data (e.g., one or more scripts stored in a markup languagedocument), in a single file dedicated to the program in question, or inmultiple coordinated files (e.g., files that store one or more modules,sub programs, or portions of code). A computer program can be deployedto be executed on one computer or on multiple computers that are locatedat one site or distributed across multiple sites and interconnected by acommunication network. Examples of communication networks include alocal area network (“LAN”) and a wide area network (“WAN”), aninter-network (e.g., the Internet), and peer-to-peer networks (e.g., adhoc peer-to-peer networks).

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform actions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinventions or of what may be claimed, but rather as descriptions offeatures specific to particular implementations. Certain features thatare described in this specification in the context of separateimplementations can also be implemented in combination in a singleimplementation. Conversely, various features that are described in thecontext of a single implementation can also be implemented in multipleimplementations separately or in any suitable sub-combination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the implementations described above should not beunderstood as requiring such separation in all implementations, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

References to “or” may be construed as inclusive so that any termsdescribed using “or” may indicate any of a single, more than one, andall of the described terms. The labels “first,” “second,” “third,” andso forth are not necessarily meant to indicate an ordering and aregenerally used merely to distinguish between like or similar items orelements.

Thus, particular implementations of the subject matter have beendescribed. Other implementations are within the scope of the followingclaims. In some cases, the actions recited in the claims can beperformed in a different order and still achieve desirable results. Inaddition, the processes depicted in the accompanying figures do notnecessarily require the particular order shown, or sequential order, toachieve desirable results. In certain implementations, multitasking orparallel processing may be utilized.

What is claimed is:
 1. A network device, comprising: a packetclassifier; a field-selection table; a hash module; a routing tablecomprising entries each associated with a respective hash value; and arouting module configured to route a packet by: determining an entry inthe packet classifier using the packet, retrieving a first identifierassociated with the determined packet classifier entry, choosing a firstfield-selection table entry using the first identifier, wherein thefirst field-selection table entry specifies a first set of bits,generating a first hash module input by identifying values of the firstset of bits of the packet specified by the chosen first field-selectiontable entry, causing the hash module to compute a first hash resultbased on the first hash module input and based on the first identifier,matching the first hash result to a first entry in the routing table,and obtaining processing data for the packet from the first routingtable entry associated, by the matching, with the first hash result; anda maintenance module configured to resolve a collision between the firsthash result associated with the first entry in the routing table and asecond hash result for a new data communication flow by: adding,responsive to detecting the collision, a new entry to the packetclassifier corresponding to the new data communication flow, wherein thenew entry includes a new identifier that is different from the firstidentifier; adding, to the field-selection table, a new field-selectiontable entry corresponding to the new identifier, wherein the newfield-selection table entry specifies a second set of bits; generating asecond hash module input by identifying values of the second set of bitsof a packet of the new data communication flow; causing the hash moduleto compute a third hash result based on the second hash module input andthe new identifier; and adding, in association with the third hashresult, an entry to the routing table comprising processing dataassociated with the new data communication flow.
 2. The network deviceof claim 1, wherein the new entry added to the packet classifier matchesat least one field of a packet associated with the new datacommunication flow.
 3. The network device of claim 1, wherein the packetclassifier is a ternary content addressable memory (TCAM).
 4. Thenetwork device of claim 3, wherein the first identifier associated withthe first packet classifier entry comprises an index in the TCAM.
 5. Thenetwork device of claim 1, wherein the field-selection table comprises atable of byte-masks.
 6. The network device of claim 1, wherein causingthe hash module to compute the first hash result based on the first hashmodule input and based on the first identifier comprises causing thehash module to use the first identifier as a seed value.
 7. The networkdevice of claim 1, wherein the routing module is configured to match thefirst hash result to the first routing table entry by: deriving arouting table index from a first subset of a set of hash result bits,wherein the hash result bits are a binary representation of the hashresult; locating an entry in the routing table from the routing tableindex; identifying a match data item stored in the entry; and verifyingthat the match data item is equal to a second subset of the set of hashresult bits, the second subset comprising at least one bit not in thefirst subset.
 8. The network device of claim 1, wherein the first hashmodule input consists of the results of an application of a maskassociated with the chosen first field-selection table entry to a singlecontiguous block of bits from the first packet, wherein the singlecontiguous block of bits comprises at least a portion of a header of thefirst packet.
 9. The network device of claim 1, the maintenance moduleconfigured to detect the collision between the first hash result and thesecond hash result for the new data communication flow.
 10. The networkdevice of claim 1, the routing module configured to retrieve the firstidentifier associated with the first packet classifier entry byretrieving an index value of the first packet classifier entry.
 11. Thenetwork device of claim 1, wherein the second set of bits specified inthe new field-selection table entry is different from the first set ofbits specified by the first field-selection table entry.
 12. A method,comprising: receiving a first packet associated with a first datacommunication flow; determining a first entry in a packet classifierusing the received first packet; retrieving a first identifierassociated with the determined first packet classifier entry; choosing afirst field-selection table entry using the retrieved first identifier,wherein the first field-selection table entry specifies a first set ofbits; generating a first hash module input by identifying values of thefirst set of bits of the received first packet specified by the chosenfirst field-selection table entry; causing a hash module to compute afirst hash result based on the first hash module input and the retrievedfirst identifier; matching the first hash result to a first entry in arouting table; obtaining processing data for the first packet from thematching first routing table entry associated, by the matching, with thefirst hash result; detecting a collision between a second hash resultfor a second data communication flow and the first hash resultassociated with the first entry in the routing table; adding, responsiveto detecting the collision, a new entry to the packet classifiercorresponding to the second data communication flow, wherein the newentry includes a new identifier that is different from the firstidentifier; adding, to the field-selection table, a new field-selectionentry corresponding to the new identifier, wherein the newfield-selection entry specifies a second set of bits; generating asecond hash module input by identifying values of the second set of bitsof a packet of the new data communication flow; causing the hash moduleto compute a third hash result based on the second hash module input andthe new identifier; and adding an entry to the routing table comprisingprocessing data associated with the new data communication flow, theadded entry associated with the third hash result.
 13. The method ofclaim 12, wherein adding the new entry to the packet classifiercomprises adding an entry that matches at least one field of a packetassociated with the new data communication flow.
 14. The method of claim12, wherein retrieving the first identifier associated with the firstpacket classifier entry comprises retrieving an index value of the firstpacket classifier entry.
 15. The method of claim 12, wherein the firsthash module input consists of the results of an application of a maskassociated with the chosen first field-selection table entry to a singlecontiguous block of bits from the received packet.
 16. The method ofclaim 12, wherein matching the first hash result to the first routingtable entry in the routing table comprises: deriving a routing tableindex from a first subset of a set of hash result bits, wherein the hashresult bits are a binary representation of the hash result; locating anentry in the routing table from the routing table index; identifying amatch data item stored in the entry; and verifying that the match dataitem is equal to a second subset of the set of hash result bits, thesecond subset comprising at least one bit not in the first subset. 17.The method of claim 12, wherein the second set of bits specified in thenew field-selection table entry is different from the first set of bitsspecified by the first field-selection table entry.
 18. A non-transitorycomputer-readable medium storing computer-readable instructions that,when executed by one or more computing devices, cause at least one ofthe one or more computing devices to: receive a first packet associatedwith a first data communication flow; determine a first entry in apacket classifier using the received first packet; retrieve a firstidentifier associated with the determined first packet classifier entry;choose a first field-selection table entry using the retrieved firstidentifier, wherein the first field-selection table entry specifies afirst set of bits; generate a first hash module input by identifyingvalues of the first set of bits of the received first packet specifiedby the chosen first field-selection table entry; cause a hash module tocompute a first hash result based on the first hash module input and theretrieved first identifier; match the first hash result to a first entryin a routing table; obtain processing data for the first packet from thefirst routing table entry associated, by the matching, with the firsthash result; detect a collision between a second hash result for asecond data communication flow and the first hash result associated withthe first entry in the routing table; add, responsive to detecting thecollision, a new entry to the packet classifier corresponding to thesecond data communication flow, wherein the new entry includes a newidentifier that is different from the first identifier; add, to thefield-selection table, a new field-selection entry corresponding to thenew identifier, wherein the new field-selection entry specifies a secondset of bits; generate a second hash module input by identifying valuesof the second set of bits of a packet of the new data communicationflow; cause the hash module to compute a third hash result based on thesecond hash module input and the new identifier; and add an entry to therouting table comprising processing data associated with the new datacommunication flow, the added entry associated with the third hashresult.
 19. The non-transitory computer-readable medium in claim 18,further comprising additional instructions that, when executed by one ormore computing devices, cause at least one of the one or more computingdevices to add the new entry to the packet classifier by adding an entrythat matches at least one field of a packet associated with the new datacommunication flow.
 20. The non-transitory computer-readable medium inclaim 18, further comprising additional instructions that, when executedby one or more computing devices, cause at least one of the one or morecomputing devices to: retrieve the first identifier associated with thefirst packet classifier entry by retrieving an index value of the firstpacket classifier entry.
 21. The non-transitory computer-readable mediumin claim 18, wherein the first hash module input consists of results ofan application of a mask associated with the chosen firstfield-selection table entry to a single contiguous block of bits fromthe received first packet.
 22. The non-transitory computer-readablemedium in claim 18, further comprising additional instructions that,when executed by one or more computing devices, cause at least one ofthe one or more computing devices to match the first hash result to thefirst routing table entry in the routing table by: deriving a routingtable index from a first subset of a set of hash result bits, whereinthe hash result bits are a binary representation of the hash result;locating an entry in the routing table from the routing table index;identifying a match data item stored in the entry; and verifying thatthe match data item is equal to a second subset of the set of hashresult bits, the second subset comprising at least one bit not in thefirst subset.
 23. The non-transitory computer-readable medium in claim18, wherein the second set of bits specified in the new field-selectiontable entry is different from the first set of bits specified by thefirst field-selection table entry.